\chapter{Tecnologies utilitzades i detalls de la implementació}

\section{Introducció}

Aquest capítol està estructurat de manera que primer s’explica la definició de
cada tecnologia que s’ha utilitzat. Després en posteriors apartats s’explica com
participa cada tecnologia a la implementació de la solució.

\section{Tecnologies i eines utilitzades}
\subsection{Programació Orientada a Aspectes}
La Programació Orientada a Aspectes, en anglès Aspect Oriented
Programming o bé AOP\footnote{AOP -
http://es.wikipedia.org/wiki/Programación\_Orientada\_a\_Aspectos}, és una
metodologia de programació força recent.\\


L'AOP és un paradigma de programació orientat a aïllar en entitats
ben definides funcionalitats secundàries,
extra-funcionals o supletories d'una lògica de negoci implementada 
en un llenguatge d'alt nivell[FIGURA crosscut.jpg]. Ajuda, mitjançant la
separació de conceptes transversals, a augmentar la modularitat del programa natiu.\\

En un programa s'enten com a concepte com un conjunt de comportaments o accions 
que aquest utilitza per a dur a terme una finalitat o requeriment. De vegades
part d'aquest conjunt d'accions es repeteixen en el codi per solucionar
diferents requeriments. La repetició d'aquest bloc de codi arreu del programa
natiu és el que s'anomena concepte transversal. Sense tenir en compte
tecnicismes d'informàtica es podria anomenar aquests conceptes
transversals com certs aspectes de l'aplicació que es repeteixen al llarg
del codi i d'aqui prové el nom d'\emph{Aspect-Oriented Programming}.\\

La materialització de l'anteriorment mencionada entitat s'anomena aspecte, en
anglés (\emph{aspect}).\\

Tot i que mitjançant l'AOP i a partir d'un codi d'alt nivell mínim es poden
resoldre aspectes funcionals de problemes complexos, o fins i tot la totalitat
del problema, no està acceptat utilitzar-la per aquesta finalitat perquè
no estaria justificat l'increment de complexitat que l'AOP
introduïria.\\


Un desavantatge important que comporta l'ús de la metodologia
AOP en una aplicació és que es fa més complex el seu desenvolupament, ja sigui en termes de
configuració o per falta de coneixemnts del programador, però el ventall de
beneficis que comporta és força gran:\\

\begin{itemize}
  \item Permet resoldre de forma clara, senzilla i eficaç problemes que en la
  capa de llenguatge d'alt nivell es ressoldrien mitjançant blocs de codis duplicats o
  repartits entre una arquitectura de dades complexa.
  \item En conseqüència del punt anterior el codi és més fàcil de mantenir.
  \item En part, gràcies també al primer punt, en el cas de conseguir reduïr una
  arquitectura de dades complexa en un sol aspecte, s'aconsegueix desacoplar
  de manera significativa el codi d'alt nivell. Un cop més, fent-lo més fàcil de
  mantenir o extendre'n les funcionalitats.
\end{itemize}


A continuació es defineixen els termes més importants de l'AOP, en anglès
per la seva claretat. Entre ells els mencionats en el paràgraf anterior:\\

\begin{itemize}
  \item \textbf{Aspect}\\Representen la solució als conceptes transversals
  que s’han mencionat prèviament. Abans de programar en AOP
  s’ha d’identificar quins ‘aspectes’ (en el sentit literal de la paraula) de
  l’aplicació es volen tractar. Un aspecte pot tenir un o més \emph{advices}
  i un o més \emph{pointcuts}, ambdós termes explicats en breu.
  \item \textbf{Joinpoint}\\Representa el punt d’execució dins
  d’un programa el qual un aspecte interceptarà. Per exemple,
  la crida a un mètode o l’assignació d’una variable.
  \item \textbf{Pointcut}\\Defineix el \emph{joinpoint} mitjançant una condició
  a complir. Aquesta definició es fa mitjançant expressions
  regulars, i gràcies a aquestes, és possible definir en un sol pointcut més
  d'un joinpoint. Mitjançant el pointcut es produïran les intercepcions als
  \emph{joinpoint} i, un cop interceptats, s'executaran els consells o
  \emph{advice}. Aquestes regles definides doncs tenen com a finalitat
  identificar crides de funcions, noms de
  variables, tipus de variables, quantitat de paràmetres, assignacions de
  valors, en definitiva, la majoria de les funcionalitats que permeti la
  definició del llenguatge d'alt nivell sobre la que treballa l'AOP, sempre i
  quan, la implementació concreta de l'AOP també ho permeti.
  \ldots
  \item \textbf{Advice}\\S’anomena consell o \emph{advice} al codi que es vol
  aplicar sobre el codi existent quan es compleixi un \emph{pointcut}, és a dir,
  quan hi hagi una ocurrència o 'match' en les definicions establertes en el
  \emph{pointcut}. Existeixen implementacions d’AOP, com AspectJ que s’explica
  en el següent subapartat, que permeten concretar d’una manera encara més profunda quan aplicarà el point cut que el connecta: abans de la crida al mètode, durant la seva execució o a la finalització del mètode.
  \item \textbf{Weaving}\\Com s’ha mencionat anteriorment, l’AOP està per sobre
  del llenguatge d’alt nivell. Degut a que el codi que te per sota és indispensable
  pel seu funcionament, el codi generat en AOP és compilat i injectat en el codi
  de l’aplicació la qual es desitja aspectuar. Aquest codi generat és
  dependent del llenguatge que hi ha per sota i això implica la necessitat d'un
  compilador d’AOP per a cada llenguatge d’alt nivell existent.\\
	
  \item 
  
  A aquest procés d’injecció
  se l’anomena \emph{Weaving} i n'existeixen de dos tipus:\\
  
  \begin{itemize}
    \item \emph{Load Time Weaving}\\Es quan el procés de \emph{weaving} es
    realitza en temps d'execució mitjançant el  \emph{ClassLoader} utilitzat per
    a carregar les classes. Aquest procés no es pot utilitzar en dispositius
    mòbils per culpa de la divisió del procés de verificació.
    \item \emph{Compile Time Weaving}\\Es quan el procés de \emph{weaving} es
    realitza en temps de compilació. Aquest procés es mostra gràficament en 
    la figura 8.1.
    
    
	\begin{figure}[H]
	\centering
	\includegraphics[width=0.7\textwidth]{imatges/chapter07/aspectweavingascodegeneration.png}
	\caption{Funcionament del procés de weaving}
	\end{figure}
    
  \end{itemize}
  

\end{itemize}

Es pot veure com interactuen tots aquests termes en la figura 8.2.

\begin{figure}[H]
	\centering
	\includegraphics[width=0.7\textwidth]{imatges/chapter07/crosscut.jpg}
	\caption{Funcionament d'AspectJ}
	\end{figure}  

Per clarificar tots els punts anteriors es proposa un exemple molt senzill:
donada una aplicació implementada en Java, es vol interceptar i llençar un
missatge per consola cada cop que l’aplicació llença un missatge per consola
mitjançant el mètode: \verb+{System.out.println(String)}+.\\ Seria el cas
del concepte a tractar.\\

Un cop identificat el concepte, es procedeix a implementar un aspecte que, com
s'ha mencionat anteriorment, contindrà en aquest cas un \emph{pointcut} i un
consell:

\begin{itemize}
  
  \item \textbf{Pointcut}\\Mitjaçant les expressions regulars que permeti la
  sintaxi de la implementació d'AOP, en aquest exemple AspectJ, 
  es defineix el \emph{pointcut} següent: tota crida durant l'execució de
  l'aplicació a un mètode anomenat \verb+{println (..)}+ s’anomena captura.\\
  
  \item \textbf{Advice}\\Per cada cop que es compleixi la regla anterior
  s'executarà el codi contingut dins del consell. En aquest exemple es vol que
  s'executi en el moment abans de la crida.
   
\end{itemize}



La part en la que s’ha de tenir més cura és en la definició del \emph{point
cut}, ja que un error aquí pot dur a terme en un comportament inesperat del
concepte transversal tractat o, fins i tot, de l'aplicació aspectuada en el cas
que des de l'aspecte se'n modifiquès el funcionament.\\

En l’anterior exemple, s’ha interceptat qualsevol crida a un mètode
println(String) i això inclou tant les crides a la funció del sistema
sistema out.println(String), com possibles mètodes
definits amb el mateix nom. Així doncs aquesta també és la part més
característica de l’AOP ja que demostra que es pot interceptar qualsevol 
mètode de l’aplicació que es té per sota.\\


Un cop implementada la solució AOP es compilaria i s'injectaria al codi Java
prèviament compilat via weaving. En la següent imatge es mostra el codi
utilitzat per aquest exemple.

	\begin{figure}[H]
	\centering
	\includegraphics[width=1.0\textwidth]{imatges/ExempleAspectJ.png}
	\caption{Procés de weaving}
	\end{figure} 


\subsection{AspectJ}\cite{AOPLIB2}\cite{AOPLIB1}
\emph{AspectJ}\footnote{AspectJ - http://www.eclipse.org/aspectj/} és una
implementació per a Java d’AOP. És un projecte existent al públic des de l’any 2001 creat inicialment per PARC i actualment desenvolupat per la
fundació Eclipse. El fet de que la seva sintaxis estigui basada en Java el fa un
llenguatge simple d’entendre almenys a nivell tècnic tenint en compte que
l’utilitzen programadors Java. És lògic, però existeixen altres implementacions
que tot i que la funcionalitat del llenguatge és la mateixa, la seva escriptura
dista molt del la del codi d’alt nivell.\\

Al ser un projecte desenvolupat per la fundació Eclipse, aquesta ha integrat
l’AspectJ en algunes de les versions del seu IDE, l’Eclipse, brindant així al
programador interessants utilitats com vistes de configuració, editors avançats
que permeten a partir d’un \emph{joinpoint}, accedir al point cut que el defineix, un
compilador integrat, i moltes més opcions. També és possible instal·lar-lo a l’IDE en forma
de plugin.

\subsection{Google Web Toolkit}\cite{GWTLIB1}
\emph{Google Web Toolkit}\footnote{GWT -
http://code.google.com/intl/es-ES/webtoolkit/}, o GWT, és un framework creat per
google per a facilitar la creació de llocs web dinàmics encapsulant la
tecnologia AJAX\footnote{AJAX - http://es.wikipedia.org/wiki/AJAX}, Asyncronus
JavaScript And XML. La web es programa íntegrament en Java, estructurant el codi d’una manera definida pel framework (seguint el principi COC, \emph{Convention Over Configuration}\footnote{COC -
http://en.wikipedia.org/wiki/Convention\_over\_configuration}). El compilador
que inclou s’encarrega de generar codi HTML + JavaScript que serà el resultat final pel navegador. Un projecte GWT es divideix en mòduls. Cada mòdul inclou codi, recursos web i arxius de configuració.\\

El codi s’estructura en dos blocs:\\

\begin{itemize}
  \item \textbf{El bloc servidor}\\Constarà de Servlets i demés classes
  Java, molt similar a qualsevol aplicació Web basada en Java
  \item \textbf{El bloc client}\\També estarà implementat íntegrament en Java.
  Aquest bloc defineix la interfície d’usuari mostrada al navegador. Conceptualment,
  s’allunya molt d’una aplicació web ordinària ja que gaudeix de moltes més
  similituds amb el desenvolupament d’interfícies gràfiques per a aplicacions
  d’escriptori. Per tal de generar la interfície gràfica es fan anar els
  elements gràfics proporcionats pel framework GWT. Un cop compilat, tot aquest
  bloc esdevindrà Javascript, gràcies tant a les eines de GWT com a la
  implementació pròpia de les llibreries de Java que incorpora. Degut a a l’ús
  d’aquestes llibreries el conjunt de classes que es poden utilitzar és limitat
  respecte a J2SE (només es poden utlitzar les classes per a les que  GWT
  proporciona implementació). Així aquest bloc serà executat al navegador.
\end{itemize}

Quant a arxius de configuració, els més importants són el web.xml, que funciona
exactament com qualsevol altra aplicació web desenvolupada en Java, i el
descriptor del mòdul. Aquest fitxer és del tipus XML, i determina les propietats
del mòdul, tals com la dependència d’altres mòduls o el punt d’entrada.\\

Cada mòdul ha de tenir com a mínim una classe que extengui la classe
\emph{EntryPoint}. Aquesta classe pot ser especificada llavors al descriptor del
mòdul com a punt d’entrada i serà la classe que s’executarà inicialment al navegador, ja que, a
l’estar definida al descriptor com a punt d’entrada, serà automàticament cridada
pel Javascript que apareix per defecte a la plana html inicial.\\

L’últim concepte, però no el menys important, és la comunicació entre classes
del bloc client i el bloc servidor. En el cas que no fos necessària aquesta
comunicació es parlaria de webs estàtiques, i el bloc de codi del
servidor estaria buit. Tot i que possible, no tindria massa sentit llavors l’elecció de
GWT per al desenvolupament de l’aplicació, ja que resultaria més senzill un
disseny basat exclusivament en html i css.\\

La comunicació en GWT és resolta mitjançant peticions (Remote Procedure Call’s)
asíncrones des del codi del bloc client cap a un servei. En realitat un servei
consta de 2 interfícies i una classe. Suposem un servei anomenat
GestioUsuaris:\\

\begin{itemize}
  \item \textbf{GestioUsuarisService}\\Seria la interfície que només indicaria
  quins mètodes estàn disponibles per les crides RPC i quins objectes retornaran.
  \item \textbf{GestioUsuarisServiceAsync}\\Ha d’estar definida al bloc
  client, seria la interfície que utilitzarà el codi del bloc client per a fer peticions. Els
  seus mètodes correspondran exactament als de la interfície
  \emph{GestioUsuarisService}, amb la única diferència que cada mètode retornarà
  null i tindrà un paràmetre extra que serà un callback, el codi del qual serà cridat
  quan la petició s’hagi resolt satisfactòriament.
  \item \textbf{GestioUsuarisServiceImpl}\\Serà la classe, definida al bloc
  servidor. Extendrà \emph{RemoteServiceServlet} (classe proporcionada pel propi
  GWT) i implementarà la interfície \emph{GestioUsuarisService}.
\end{itemize}

Els paràmetres emprats als mètodes del servei, així com els objectes que poden
retornar els mètodes, poden ser qualsevol tipus primitiu de Java o bé qualsevol
objecte Java que sigui suportat per la implementació de la llibreria Java de
GWT, així com qualsevol objecte Java definit al bloc client que pugui ser
serialitzat.

\subsection{Altres tecnologies i eines}
\begin{itemize}  
  \item \textbf{Ant}\\Apache Ant\footnote{Ant -
  http://es.wikipedia.org/wiki/Ant} és una eina de software utilitzada per automatitzar processos de compilació i construcció. Funciona definint les tasques a
  realitzar en un fitxer XML i, ja sigui des de consola o bé programàticament,
  se li va especificant quines tasques es desitja que realitzi. Per tal
  d’utilitzar-lo programàticament resulta fàcil d’integrar-lo en projectes Java
  ja que ha estat escrit amb aquest mateix llenguatge. La seva llicència és
  Apache License 2.0.
  \item \textbf{Drools}\\Drools\footnote{Drools - http://jboss.org/drools/} és
  un conjunt d’eines desenvolupades per la JBoss Community. Es tracta d’una plataforma de Business Logic Integration, de la qual només s’ha
  utilitzat Drools Expert en aquest projecte. Drools Expert és un motor
  d’inferència basat en regles desenvolupat íntegrament en Java. El fet que
  sigui fàcilment integrable en projectes Java i, sobretot, que permeti l’ús de
  Java Beans com a base de coneixement han fet que es descartés Jess, el motor
  d’inferència basat en regles que es pensava utilitzar inicialment per al component 
  servidor.
  \item \textbf{Tomcat Apache}\\Tomcat\footnote{Tomcat -
  http://tomcat.apache.org/} és un famós servidor d’aplicacions open source creat i mantingut per la fundació Apache. La seva llicència és Apache License
  version 2.
  \item \textbf{Wireless Universal Resource FiLe}\\Durant el transcurs d’aquest document cada cop que s’ha fet
  referencia a WURFL\footnote{WURFL - http://wurfl.sourceforge.net/},
  \emph{Wireless Universal Resource FiLe}, s’ha anomenat base de dades de perfils de dispositiu.
  WURFL no és res més que un fitxer XML on hi són perfectament definits tots
  aquests perfils. Es tracta d’un projecte open source i això implica que aquest fitxer sigui actualitzat cada cert temps gràcies al fort recolzament de la comunitat
  vers aquesta eina. Des del propi portal web, es poden descarregar llibreries
  per diversos llenguatges de programació com poden ser Java, .NET o PHP.
  \item \textbf{JDBC}\\\emph{Java Data Base Connectivity}\footnote{JDBC -
  http://es.wikipedia.org/wiki/Java\_Database\_Connectivity} és una API que
  ofereix Java per a la conexió amb bases de dades que cumpleixin amb els estandards ODBC. En aquest projecte s’ha fet anar el MySQL JDBC Connector.
  \item \textbf{JDOM}\\\emph{Java Document Object Model}\footnote{JDOM -
  http://www.jdom.org/} és una llibreria de Java per a gestionar contingut XML programàticament.
  \item \textbf{Llibreries d'Apache Commons}\\Durant el desenvolupament del
  sistema, per a dur a terme certs requisits funcionals ha sorgit la necessitat d’incloure 
  com a dependències, sobretot al servidor, diverses llibreries d’\emph{Apache
  commons}\footnote{Apache commons - http://commons.apache.org/}. Entre elles
  estan, per exemple, FileUpload, BeanUtils, IO o Collections.
  \item \textbf{XML}\\eXtensive Markup Language és un meta-lleguatge especificat
  pel W3C. El seu objectiu és codificar informació de forma que aquesta pugui ser entesa
  fàcilment per un sistema informàtic. Actualment és una tecnologia molt
  utilitzada.
  \item \textbf{DTD}\\S’ha utilitzat aquesta tecnologia, \emph{Document Type
  Definition}\footnote{DTD -
  http://es.wikipedia.org/wiki/Definición\_de\_tipo\_de\_documento}, per al
  correcte funcionament del pas de missatges entre servidor i client. Serveix per a definir la estructura de contingut xml.
  \item \textbf{MySQL}\\MySQL\footnote{MySQL - http://www.mysql.com/} és un
  gestor de base de dades relacional amb llicència GNU GPL. Segons wikipedia n’existeixen almenys sis milions d’instal·lacions.
  \item \textbf{CVS}\\\emph{Concurrent Versions System}\footnote{CVS -
  http://es.wikipedia.org/wiki/CVS}, és una eina de lliure distribució orientada a portar un control de versions de codi font. S’ha emprat
  durant tot el desenvolupament del projecte per tal de desenvolupar-lo
  col·laborativament i de forma segura i ordenada.
  \item \textbf{Google Docs}\\Famosa eina\footnote{Google Docs -
  http://docs.google.com} de Google que s’ha emprat tant per a dur a terme la documentació del projecte com per a portar una mena de seguiment
  d’errors durant el procès d’implementació. Es tracta d’una suite d’ofimàtica
  amb propietats col·laboratives molt interessants.
  \item \textbf{Llistes de distribució}\\S’ha fet ús de llistes de distribució
  de les comunitats de Google Web Toolkit, J2ME i AspectJ.
  \item \textbf{Eclipse}\\És un entorn de desenvolupament integrat (IDE) que
  s’ha utilitzat per desenvolupar tots els mòduls que composen el component client.
  Està desenvolupat íntegrament en Java tot i que, al utilitzar SWT com a
  llibreria gràfica, és depenent de plataforma. Està disponible mitjançant la
  llicència Eclipse Public License\footnote{Eclipse Public License -
  http://www.eclipse.org/legal/epl-v10.html}.
  \item \textbf{Netbeans}\\És un entorn de desenvolupament integrat (IDE) que
  s’ha utilitzat per desenvolupar tant el component servidor com la web. Està
  desenvolupat per Sun Microsistems (ara Oracle) íntegrament en Java.
  \item \textbf{GWT4NB}\\És un plugin per a Netbans que ofereix suport per al
  desenvolupament d’aplicacions web mitjançant el framework Google Web Toolkit.
  \item \textbf{Latex}\\S’ha utilitzat aquest sistema de composició de documents
  basats en TeX. És open source i la  seva llicència és Licencia Pública del Proyecto
  LaTeX LPPL.
  \item \textbf{Dia}\\Dia és un editor de diagrames open source i s’ha utilitzat
  per a la creació dels diferents gràfics d’aquest document. La seva llicència és GNU
  GPL.
  \item \textbf{MTJ}\\MTJ o Mobile Toolkit for Java és un plugin per a Eclipse
  que facilita el desenvolupament per a dispositius mòbils.
  \item \textbf{AJDT}\\AJDT o AspectJ Developer Tools és un plugin per a Eclipse
  que proporciona al desenvolupador diverses eines, un compilador i la pròpia
  llibreria AspectJ, per a facilitar el desenvolupament amb aspectes en la
  plataforma Java.
  \item \textbf{WTK}\\El Wireless ToolKit seria pels dispositius mòbils el que
  Java SDK és per als sobretaula. És un conjunt de llibreries, eines i emulador
  distribuits per Sun que permeten utilitzar el llenguatge Java (J2ME) per al
  desenvolupament d’aplicacions en dispositius mòbils. Aquest es distribueix
  tant per al desenvolupament en plataformes Linux com Windows.
  \item \textbf{Google Project Hosting}\\S'ha utilitzat aquesta
  eina\footnote{Google Project Hosting - http://code.google.com/hosting/} de
  Google per a la documentació millorant les capacitats de google docs.
  \item \textbf{SVN}\\Es un dels sistemes de control de versions que ofereix
  google per a gestionar el codi font dels seus projectes. S'ha instal·lat el seu client al
  Netbeans.
  
 
\end{itemize}

\section{Detalls de la implementació}
A continuació s’explica finalment com s’ha dut a terme la solució en termes
d’implementació. Primer s’explica el client i després el servidor.\\
Durant tot el procés de desenvolupament s’ha intentat seguir l’estandard de les
Java Naming Conventions, és a dir, escrivint segons aquestes tots els noms dels
beans, atributs, mètodes, variables i clases.

\subsection{Client}
El client, anomenat fins ara component client, és la part de software que
s’injectarà a l’aplicació a adaptar. S’ha optat per una implementació íntegra en
Java, però degut a que es va pensar en donar suport tant a aplicacions J2SE i
J2ME en una única solució, s’ha hagut de fer un disseny modular per tal de poder
reciclar el màxim de codi possible.\\

Aquest disseny modular consta de 3 capes o tipus de mòdul:\\
\begin{itemize}
  \item \textbf{*.common}\\
  Inclou la implementació de la lògica principal de la solució, així com les
  interfícies que hauran d’implementar les altres capes.
  \item  \textbf{*.platform}\\
  A aquesta capa s’implementen les interfícies proporcionades per la capa comuna
  que són depenents de plataforma. Hi haurà doncs un mòdul d’aquest tipus per
  cada plataforma suportada al sistema (actualment hi han dos implementats: un
  per a J2ME i un altre per a J2SE).
  \item \textbf{*.ui}\\
  Aquesta és la capa que es vincula amb les llibreries gràfiques de l’aplicació
  mitjançant AOP. Un mòdul d’aquesta capa ha d’incloure la capa aspectual necessària, els mecanismes de selecció de ProposalSet i obtenció de feedback així com especificar quines implementacions de les disponibles han de ser utilitzades. Hi haurà doncs una implementació d’aquesta capa per a cada llibreria gràfica a la que es vulgui donar suport. S’han implementat els mòduls per a LWUIT i LCDUI (J2ME) i AWT, SWT i Swing(J2SE).
\end{itemize}
 

\subsubsection{Capa *.common}
\textbf{Compatibilitat de compilació amb l’entorn d’execució de
CDC-1.1/Foundation-1.1}
Com s’ha mencionat en el capítol de Java la solució
existeix tant per entorn d’escriptori com per a dispositius mòbils. Aquests últims però tenen limitacions
de processament i per tant tenen un joc d’instruccions molt més reduït. Llavors
la solució passa per obligar al desenvolupador a implementar un codi que compili
amb l’entorn d’execució CDC 1.1.\\

N’hi ha hagut prou doncs, en crear un projecte Java, i marcar l’opció a les propietats de projecte. 
Malauradament pel fet de fer el projecte compatible amb CDC i no haver-hi
l’opció que també ho sigui per CLDC, no hi ha restricció a nivell de compilador
a l’hora de crear codi per CLDC i el programador ha de ser concient del codi que
hi posa ja que pot no funcionar en dispositius que utilitzin CLDC.\\

Les restriccions CDC impedeixen, per exemple, utilitizar qualsevol de les
funcionalitats del java 5 com ara els Generics, o també qualsevol implementació
de List. Totes aquestes limitacions han fet d’aquest projecte una mica més
complex d’implementar.\\

\textbf{Fitxer de propietats}
Aquest fitxer és generat pel component Web després de crear una
adaptació i consta d’una serie de metadades, tuples clau=valor, essencials per al correcte
funcionament del component client i del sistema en general.\\

Els més importants són:\\
\begin{itemize}
  \item	\textbf{userId}\\És l’identificador única d’un component client concret.
  \item \textbf{serverURL}\\És la cadena de conexió amb el servidor.
  \item \textbf{connectionType}\\Indica quin protocol de conexió utilitzarà el
  dispositiu.
  \item \textbf{persistenceType}\\Indica quin protocol de persistència
  utilitzarà el dispositiu.
  \item \textbf{uiType}\\Indica quina llibreria gràfica utilitzarà el
  dispositiu.
  \item \textbf{feedback}\\Indicador booleà sobre la presència de la pantalla de
  satisfacció o no.
  \item \textbf{feedbackRank}\\Rang màxim en l’escala de la pantalla de
  satisfacció.
\end{itemize}

\textbf{Interfícies que han de ser proporcionades per les altres capes}
Aquest mòdul necessita de certes classes que inexorablement dependran de
plataforma. Aquestes classes seran proporcionades per les altres capes del
component client, però la seva definició (la interfície que implementen, parlant
de Java) ha de ser definida aquí. Les interfícies que es presenten a la resta de
capes són les següents:\\

\begin{itemize}
  \item \textbf{Server}\\Aquesta intefície defineix com el component client
  interactuarà amb el component servidor.
  \item \textbf{Persistence}\\Aquesta interfície defineix una cache local, que
  utilitzarà el component client per emmagatzemar logs fins que no s’enviïn. Aquest pas és
  necessari ja que sempre pot haver-hi problemes de connectivitat.
  \item \textbf{Transformer}\\Aquesta interfície s’encarrega de transformar les
  dades obtingudes pel servidor a Java Beans. Actualment només hi ha una implementació
  d’aquesta interfície (XmlTransformer), que és proporcionada per aquest mateix
  mòdul. Per a més informació consultar Desacoblar l’XML, abstraient el protocol
  de comunicació, al capítol 11: Conclusions i Treball Futur.
  \item \textbf{UIAdapter}\\Aquesta interfície treballa directament amb objectes
  de la interfície d’usuari. A partir d’un ProposalSet determina si els objectes de la
  interfície que li envia la capa aspectual han de ser adaptats o no i, en cas
  afirmatiu, aplica els canvis pertinents.
  \item \textbf{ConcreteFactory}\\Aquesta interfície proporcionarà les classes
  concretes que implementen les interfícies anteriorment esmentades. Quan el component
  s’inicia, el primer pas a fer és inicialitzar els controladors del mòdul comú
  amb la ConcreteFactory proporcionada al mòdul de les llibreries gràfiques,
  així el mòdul comú ja pot obtindre les implementacions que necesita pel seu
  funcionament.
\end{itemize}

\textbf{Controladors}
Aquest mòdul té dos controladors, que són els que implementen tota la lògica del
component client comuna per a totes les plataformes. Els controladors són
inicialitzats i utilitzats directament per la capa aspectual.\\

Els controladors són:\\
\begin{itemize}
  \item \textbf{LogController}\\Gestiona tota la part d’emmagatzematge i
  tractament la informació capturada pels aspectes, tant sobre la captura de la interfície
  d’usuari com sobre les accions de l’usuari sobre la mateixa.
  \item \textbf{ProposalController}\\Gestiona el tractament de propostes i
  proporciona la implementació de UIAdapter a qui la necesiti.
\end{itemize}

\subsubsection{Capa *.platform}
A diferència de l’anterior aquest projecte pot utilitzar qualsevol
versió/compilador de Java SDK sempre i quan en el dispositiu existeixi un entorn
d’execució compatible.\\
Ha d’implementar únicament les interfícies proporcionades per la capa comuna que
són depenents de plataforma. Aquestes interfícies són Server i Persistence. Cal
tindre en compte, però, que un mòdul d’aquesta capa pot proporcionar diverses implementacions per a la mateixa interfície, deixant a l’implementador
de la ConcreteFactory l’elecció de quina de les implementacions es vol utilitzar
en un cas concret.\\
Actualment s’han proporcionat dos projectes diferents, és a dir, s’ha
implementat suport per a dues plataformes:\\

\begin{itemize}
  \item \textbf{J2ME}\\Proporciona una implementació de Persistence: RMSManager.
  Aquesta classe es basa en la API RMS javax.microedition.rms de J2ME per a
  l’emmagatzemament de dades en persistència local del dispositiu.\\Proporciona
  una implementació de Server: HttpServer. Aquesta classe es basa principalment
  en la classe javax.microedition.io.HttpConnection (proporcionada per CDC) per
  a oferir un canal de comunicació HTTP amb el component servidor.
  \item \textbf{J2SE}\\Proporciona una implementació de Persistence:
  FastFSManager. Aquesta classe empra el sistema de fitxers del sistema per tal d’emmagatzemar
  dades.\\Proporciona dues implementacions per a Server:\\
  \begin{itemize}
    \item \emph{DesktopHttpServer}\\Basada en HttpClient (llibreria
    proporcionada per Apache Commons)
    \item \emph{FakeDemoServer}\\Implementació creada amb motius de depuració
    i desenvolupament. Aquesta implementació de Server no es comunica amb un
    component servidor, sinó que l’emula. Per tal d’emular-lo fa veure que envia
    dades (que no són tractades ni emmagatzemades enlloc) i envia una resposta
    que obté directament del sistema de fitxers. Així el desenvolupador pot
    controlar la resposta que s’envia.
  \end{itemize}
\end{itemize}

\subsubsection{Capa *.ui}
L’última capa del component client és la única que conté tecnologia AOP. Aquesta
capa proporciona doncs l’enllaç entre l’aplicació que es vol adaptar i els
controladors implementats a la capa comuna, a més de tot el que depengui
explícitament de la llibreria gràfica que utilitza l’aplicació, com ara la
pantalla de selecció de proposal set o bé la de feedback. Per tal d’ajudar al
desenvolupament es va decidir separar els aspectes en tres tipus ja que
conceptualment s’utilitzen per a tres funcions ben diferenciades:\\

\begin{itemize}
  \item \textbf{Capturar el cicle d’aplicació}\\Aquest aspecte té la missió de
  detectar quan s’ha iniciat l’aplicació per a inicialitzar el component client. A més ha
  de capturar també quan es vol tancar l’aplicació i comunicar-ho als
  controladors, per si tenen que fer alguna tasca abans de deixar d’existir (com
  tancar canals de comunicació, finalitzar correctament el procés persistència,
  etc).\\Finalment també poden tindre en compte situacions de canvi, com que al
  mòbil rebem una trucada o que a l’escriptori es minimitzi l’aplicació que
  s’està monitoritzant. Aquests events afecten al cicle de l’aplicació, per
  exemple, a l’hora de determinar el temps d’ús d’una finestra o el temps de
  resposta d’un usuari.
  \item \textbf{Capturar la interfície gràfica}\\Aquest aspecte s’ha
  d’encarregar de capturar la creació i destrucció de finestres a l’aplicació, i emmagatzemar
  els elements que les formen amb els Beans que ofereix la capa comuna. Un cop
  les finestres es volen destruir ha de comunicar-ho al LogController, que
  s’encarrega de monitoritzar el temps que han estat obertes i desar-les
  apropiadament.\\A més a més quan es crea una nova finestra o un nou element a
  la interfície aquest aspecte és l’encarregat d’aplicar-li els canvis descrits
  al proposal set.
  \item \textbf{Capturar les accions d’usuari}\\Aquest aspecte s’ha d’encarregar
  de capturar tota interacció de l’usuari amb la interfície gràfica.
\end{itemize}

A més de proporcionar la capa aspectual i les pantalles de selecció de
ProposalSet i de feedback, aquesta capa també té la responsabilitat de
determinar quines classes s’han d’utilitzar per a satisfer les interfícies de la
capa comuna. Així doncs aquesta capa ha de proporcionar una implementació de la
interfície ConcreteFactory, tot retornant una instància de la classe que es
vulgui utilitzar, mitjançant el fitxer de propietats, per a la interfície que
representa cada mètode.\\

S’han implementat els següents projectes que proporcionen aquesta capa:\\
\begin{itemize}
  \item \textbf{*.j2me.lcdui}\\Suporta la llibreria gràfica LCDUI, que utilitzen
  algunes aplicacions J2ME. Cal destacar que aquesta llibreria és molt bàsica i per tant
  la monitorització és molt limitada.
  \item \textbf{*.j2me.lwuit}\\Suporta la llibreria gràfica LWUIT, per a J2ME.
  \item \textbf{*.j2se.awtSwing}\\Suporta tant AWT com Swing en entorns J2SE. Ha
  estat programada amb Java 6 així que no funcionarà a entorns amb un JRE de versió
  inferior encara que l’aplicació que es vol adaptar estigui desenvolupada amb
  una versió anterior de Java.
  \item \textbf{*j2se.swt}\\Suporta SWT per a entorns J2SE que disposin
  d'implementació d'aquesta llibreria. Com que SWT no és multiplataforma aquest
  mòdul utilitza Swing per a les pantalles de selecció de propostes i la de feedback.
\end{itemize}

	\begin{figure}[H]
	\centering
	\includegraphics[width=1\textwidth]{imatges/chapter07/componentClient.png}
	\caption{Diagrama de dependència del component client implementat per a LWUIT}
	\end{figure} 


\subsection{Servidor}
Al capítol anterior es parlava del component servidor i de l’aplicació web com a
dos components completament separats. Des del punt de vista de la funcionalitat
això és cert. A l’hora de proporcionar una implementació, però, té molt més
sentit la seva fusió, ja que s’ha optat per implementar-los amb les mateixes
tecnologies. La web ha sigut implementada mitjançant GWT, que utilitza Java
Servlets mentre que al component servidor s’ha optat per emprar un canal HTTP
per a la comunicació amb el client. Per implementar aquest canal, doncs,  s’ha
decidit utilitzar també Java Servlets i reduir així l’impacte que suposaria
utilitzar altres tecnologies.

\subsubsection{Web}
Degut a que s’ha decidit no optar per cap capa de més alt nivell a l’hora de
treballar amb GWT s’han hagut d’utilitzar alguns patrons i convencions per tal
de facilitar la feina el màxim possible. Aquestes facilitats són les següents:

\begin{itemize}
  \item \textbf{Patró Model-Vista-Controlador}\\S’ha optat per utilitzar el
  patró MVC per a la implementació de la part dinàmica de la interfície d’usuari. Així cada
  pantalla de la web es divideix en tres components:\\
  \begin{itemize}
    \item \textbf{Vista (arxius *view.java)}\\Defineix, mitjançant els
    components que ofereix el framework GWT, la interfície d’usuari. Totes les vistes extenen
    la classe FlowPanel, proporcionada pel GWT, que esdevé un element DIV un cop
    compilada.
    \item \textbf{Model (arxius *model.java)}\\Emmagatzema l’estat de la vista,
    així com les dades que aquesta necesiti mostrar.
    \item \textbf{Controlador (arxius *controller.java)}\\Proporciona tota la
    lógica de la vista. Això pot incloure demanar dades al servidor per actualitzar el
    model, enviar dades del model al servidor pel seu emmagatzemament i
    validació de les dades que l’usuari insereix a la vista.
    \end{itemize}
    
    \item \textbf{Patró Observer}\\Per tal que la vista s’assabenti quan hi ha
    hagut un canvi al model es fa ús del patró Observer. S’ha definit doncs una
    interfície anomenada Observer, que és implementada per les vistes. Aquesta
    interfície consta d’un sól mètode, anomenat update, que és cridat pel model
    quan aquest rep algun canvi. Per tal que el model pugui tractar Observers,
    s’ha implementat la classe abstracta Observable, que defineix mètodes per
    registrar Observers i avisar-los quan sigui necesari. El llenguatge Java
    ofereix un patró similar inclós a les seves llibreries. S’ha optat per una
    implementació pròpia, però, degut a que aquest codi esdevindrà Javascript un
    cop compilat, i la implementació que ofereix Java no és compatible
    actualment amb el compilador Javascript de GWT.
    \item \textbf{SoftCallback}\\Com s’ha mencionat anteriorment, per tal de
    poder fer una crida RPC (necesària per enviar o demanar dades al servidor), es precisa
    implementar un callback, que s’executarà quan la crida s’hagi resolt, ja
    sigui satisfactòriament o no. GWT proporciona una interfície, anomenada
    AsyncCallback, que consta de dos mètodes: onFailure i onSuccess. Per tal de
    no repetir codi i oferir un comportament comú davant un error en la crida
    RPC (com pot ser la pèrdua de connectivitat, per exemple) s’ha implementat
    la classe abstracta SoftCallback, que implementa el mètode onFailure
    d’AsyncCallback.
    \item \textbf{AbstractService}\\Es tracta d’un Service abstracte, que
    implementa mètodes bàsics que requereixen la gran majoria de Services, com ara
    l’obtenció de l’usuari autenticat al sistema actualment, etcètera.
    \item \textbf{ProjectBuilder}\\El ProjectBuilder és el mòdul de software
    capaç de compilar aplicacions Java. S’ha implementat de forma genèrica, i fa ús del
    projecte Apache Ant. Aquest mòdul s’utilitza per a injectar de forma
    automàtica el component client a les aplicacions que es volen adaptar.
    Requereix de certes dades, però, per a oferir l’aplicació adaptada. Aquetes
    dades són: el codi font de l’aplicació a adaptar, el codi font dels mòduls
    del component client que es vol injectar, diverses dades necesàries per a la
    compilació, que depenen de la plataforma (J2ME ó J2SE, actualment), el
    build.xml per a la plataforma seleccionada i la ID de l’adaptació. Totes
    aquestes dades existeixen a la base de dades.
    \item \textbf{JDBCUtil}\\Aquesta classe proporciona mètodes per a
    simplificar l’accés a la base de dades. Encapsula totes les crides JDBC i permet als Service
    treballar directament amb objectes del tipus CachedRowSet.
\end{itemize}

\subsubsection{Component servidor}
El component servidor disposa d’un Servlet, anomenat LogReceiver, que
s’encarrega d’esperar logs. Per cada log que rep, retorna un proposal set al
client que li ha enviat. S’ha decidit però deixar que aquesta classe només
s’encarregui de la lògica del procés, i actuï a nivell de controlador. Per tal
d’emmagatzemar el log rebut i obtindre un proposal set que retornar LogReceiver
fa ús de la classe LogUtils. Tanmateix LogUtils es comunica amb la base de dades
(tant per emmagatzemar el log com per a obtindres les dades a passar al motor
d’inferència) a través de la classe JDBCUtil, anomenada a l’apartat anterior. A
més genera respostes a través d’una interfície anomenada InferenceEngine, que
representa una capa d’abstracció respecte al motor d’inferència concret que es
vol utilitzar.\\
Es proporciona una implementació de InferenceEngine que utilitza Drools com a
motor d’inferència, a la classe DroolsInferenceEngine.


\subsection{Comunicació bidireccional client-servidor}
Per tal de que la comunicació a dos bandes entre el client i servidor sigui
efectiva i a prova d'errors s'ha decidit estabir un protocol de comunicació
basat en XML. Per tal de validar aquest XML tant en el client com en el servidor
es dissenya un Document Type Definition, DTD.\\

A l'existir dos tipus de comunicacions, d'una banda client-servidor i per
l'altra servidor-client, amb funcionalitats clarament diferents s'ha generat un
DTD per a cada cas.\\

\lstset{
basicstyle=\scriptsize 
}

\begin{itemize}
  \item \textbf{Client-servidor}\\El component client és l'encarregat de
  recollir en forma de logs el contexte d'ús entre l'usuari i l'aplicació. Aquests logs en
  XML són creats en el component client complint en el següent DTD:\\
  \begin{lstlisting}
 <!DOCTYPE MESSAGE [
<!ELEMENT MESSAGE (LOG+)>
<!ELEMENT LOG (HEAD,BODY)>
	<!ATTLIST LOG	ID	ID	#REQUIRED>
<!ELEMENT HEAD (USER,DEVICE,DATE,APPLICATION)>
<!ELEMENT USER (#PCDATA)>
<!ELEMENT DEVICE (#PCDATA | (PROPERTY+))>
<!ELEMENT PROPERTY ID (#PCDATA)>
	<!ATTLIST PROPERTY ID	ID	#REQUIRED>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT APPLICATION(NAME,VERSION,TYPE,JAVA)>
<!ELEMENT NAME (#PCDATA)>
<!ELEMENT VERSION (#PCDATA)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT JAVA (#PCDATA)>
<!ELEMENT BODY (FRAME+)>
<!ELEMENT FRAME (TIME,CONTAINER,EVENTS+)>
	<!ATTLIST FRAME	ID	ID	#REQUIRED>
<!ELEMENT TIME (#PCDATA)>
<!ELEMENT CONTAINER (LAYOUT,TYPE,WIDGET+,CONTAINER+)>
<!ELEMENT LAYOUT (#PCDATA)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT WIDGET (HSIZE,VSIZE,FOREGROUND_COLOR,
	BACKGROUND_COLOR,TYPE,FONT)>
		<!ATTLIST WIDGET	ID	ID	#REQUIRED>
<!ELEMENT HSIZE (#PCDATA)>
<!ELEMENT VSIZE (#PCDATA)>
<!ELEMENT FOREGROUND_COLOR (#PCDATA)>
<!ELEMENT BACKGROUND_COLOR (#PCDATA)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT FONT (TYPE,SIZE,STYLE)>
<!ELEMENT TYPE (#PCDATA)>
<!ELEMENT SIZE (#PCDATA)>
<!ELEMENT STYLE (#PCDATA)>
<!ELEMENT EVENTS (GAIN_FOCUS, LOST_FOCUS,
	 ACTION_PERFORMED)*>
<!ELEMENT GAIN_FOCUS (TIME)>
<!ELEMENT TIME (#PCDATA)>
<!ELEMENT LOST_FOCUS (TIME)>
<!ELEMENT TIME (#PCDATA)>
<!ELEMENT ACTION_PERFORMED (TIME)>
<!ELEMENT TIME (#PCDATA)>
]>
\end{lstlisting}

No s'explica tot el DTD sencer, però s'explicarà els trets més importants que
tenen a veure amb tot el que s'ha anat explicant durant aquest capítol:\\

Segons aquest DTD, un missatge enviat al servidor és anomenat pel sistema
\verb+<MESSAGE>+ i aquest pot contenir un o més logs \verb+(LOG+)+.\\

Un element \verb+<LOG>+ correspon a una sessió sencera del context d'ús
entre l'usuari i l'aplicació. Donat el cas que en una sessió no es pogués enviar
l'XML amb aquesta informació sobre el context d'ús al component servidor, el component
client ha de ser capaça d'enmagatzemar-lo i en una sessió posterior, continuar
monitoritzant el context en el mateix fitxer XML en forma de un nou
\verb+<LOG>+.\\

Cal destacar també que cada un dels \verb+<LOG>+ enviats té dos elements
importants: \verb+<HEAD>+ i \verb+<BODY>+. El primer conté metainformació que és
essencial per al component servidor per a poder identificar el component client
que esta intentant comunicar-se amb ell a l'hora de rebre el missatge. 
L'altre element, \verb+<BODY>+, conté la informació monitoritzada durant la
sessió com ara els temps entre pantalles, els widgets i les
seves característiques, les fonts i els events.

  \item \textbf{Servidor-client}\\ El component servidor és qui envia en format
  XML els canvis proposats al component client. Donat que el capítol següent s'estudia la
  capacitat d'adaptació del component client s'ha cregut més adient
  mostrar-hi allí el DTD corresponent per aquest cas.
\end{itemize}

 

\section{Tecnologies provades i descartades}
\begin{itemize}
  \item \textbf{EclipseME}\\EclipseME és un plugin que permet desenvolupar
  projectes per a dispositius mòbils amb J2ME sota Eclipse. Aquest plugin va deixar de rebre
  suport i actualment ha estat substituït per MTJ. Requereix tindre WTK ó JavaME
  SDK instal·lats al sistema. Diversos errors a l’hora de construir el paquet
  per culpa d’una incompatibilitat de versions entre aquest i l’Eclipse.
  \item \textbf{JavaME SDK}\\És el substitut en l’actualitat de WTK, inclou
  llibreries noves i d’altres actualitzades. Ha estat descartat perquè actualment només és
  suportat en la plataforma Windows.
  \item \textbf{Major \& Ferrari}\\Es tracta d’una llibreria que permet capturar
  crides a mètodes, atributs, instàncies, etc, semblant a les funcionalitats que ofereix
  AspectJ, però actúa a més baix nivell. Això li permet poder capturar crides
  que resulten invisibles per a AspectJ. Aquesta llibreria està basada en una
  tecnologia anomenada Ferrari, que es comunica amb la JVM i permet aquesta
  captura a baix nivell. Bàsicament Major és una llibreria que permet l’ús de
  les funcionalitats de Ferrari de forma relativament més còmoda per al
  desenvolupador.\\
  Es va pensar que es necessitaria d’aquesta funcionalitat per
  tal de poder capturar mètodes de la llibreria gràfica que es criden
  implícitament. Això és, per exemple, quan un mètode no es crida des d’on un
  aspecte d’AspectJ tindria accés, és a dir des de l’aplicació, sinó que la seva
  crida prové, per exemple, perquè es requereix redibuixar una finestra quan la
  finestra que tenia una capa per sobre s’ha mogut.\\Major va donar força
  problemes quant a configuració i ús, i a més només servia per a J2SE (J2ME,
  afortunadament, és un entorn força més controlat on n’hi ha prou amb les
  captures de mètodes cridats explícitament). Finalment es va descartar ja que
  es van trobar solucions alternatives basades en AspectJ on no feia falta
  capturar crides implícites d’events.
  \item \textbf{Groovy \& Grails}\\Aquesta recerca parteix d’una prèvia
  aplicació client servidor realitzada per un antic alumne: Jordi Monné. El servidor estava
  implementat en Grails. El client era un lector de ‘Feeds’ fet en J2ME amb la
  llibreria gràfica LCDUI. Abans de fer la migració a LWUIT es va tenir que
  entendre el funcionament d’aquest servidor. Llavors mencionar que Groovy és
  una alternativa al llenguatge Java i Grails és un framework que extèn el
  llenguatje Groovy.\\
  Finalment, per aquest projecte es va preferir l’opció
  J2EE + Tomcat gràcies a que és més entenedora, més utilitzada i per tant més
  documentada a la web i per la qual hi ha moltes més eines com podria ser GWT,
  també molt utilitzades.
  \item \textbf{AJDE}\\És un plugin que permet desenvolupar projectes amb
  AspectJ des de l’IDE Netbeans. Es va provar per intentar desenvolupar el projecte íntegrament
  amb Netbeans ja que aquest IDE integra força millor les tecnologies pel
  desenvolupament de J2ME però el suport d’AspectJ a Eclipse està força més
  madur. Aquest plugin funciona força be quan s’ha d’utilitzar amb J2SE però és
  incapaç de compilar un projecte J2ME amb suport per a AspectJ.
  \item \textbf{Jess}\\Jess és un motor d’inferència basat en regles i
  desenvolupat en Java. Aquest motor té dos inconvenients per a aquest projecte
  que han fet que s’acabés utilitzant Drools Expert en comptes d’ell. Aquest defectes són la
  seva llicència privativa (tot i que ja s’havia otorgat al projecte una
  llicència educativa permetent el seu ús), i el sobrecost que provoca haver
  de definir la base de coneixement en un llenguatge diferent del de Java abans
  de poder introduir les dades al motor d’inferència.
  \item \textbf{Jetty}\\Jetty és un servidor d’aplicacions que actualment és
  mantingut per la fundació Eclipse i és famós per ser molt lleuger. Es va
  descartar perquè era complicat configurar-lo correctament per al desplegament de
  l’aplicació web.
  \item \textbf{Swing Look And Feel} (LAF)\\Swing suporta l’ús de temes per la
  decoració dels elements de la interfície d’usuari. Aquests temes, o Look And Feel a
  l’argot de Swing, es van estudiar per tal d’aplicar un canvi notori a la
  interfície i després deixar que el motor d’inferència anés polint els
  detalls mitjançant la proposta de petits canvis o be directament proposar l’ús
  d’un nou LAF. Aquesta branca del projecte, però, va ser descartada tot i haver
  construït una demostració que era capaç de canviar el LAF d’una aplicació
  programàticament de forma dinàmica (és a dir, mentre l’aplicació estava sent
  utilitzada, descarregant el LAF via HTTP i sense tocar el codi de l’aplicació
  en cap moment).\\
  
  El principal motiu per descartar-la va ser el nivell extra
  de complexitat que calia afegir al protocol de comunicació entre component client
  i component servidor, i especialment l’augment de complexitat quant a la
  fabricació de regles pel motor d’inferència, ja que s’hauria de tindre també
  en compte el LAF aplicat a l’hora de suggerir canvis. A més a més es perdia
  una de les major virtuds de la solució, la abstracció de la llibreria gràfica
  emprada per l’aplicació, ja que aquesta tècnica només és compatible amb Swing.
  \item \textbf{SQLite}\\SQLite  és un gestor de base de dades relacional de
  lliure distribució molt lleuger. Està escrit en C i ocupa força menys d’1Mb. No
  s’executa com a servidor sinó que s’utilitza en forma de llibreria. Actualment
  està integrat a molts grans projectes, que van des de Firefox i Skype a la
  majoria dels sistemes operatius per a mòbils(Android, iOS, Symbian, Maebo i
  Meego entre d’altres). Es va descartar SQLite perquè MySQL disposa de millors
  eines d’administració i ús i una comunitat molt més gran.

\item \textbf{Spring AOP}\\
Spring és un framework molt popular al món Web. Es tracta d'un framework amb un
disseny modular que pretén simplificar i fer més robusta i eficient la
programació de pàgines web amb Java.\\

Una de les seves característiques és que té el seu propi framework AOP, el qual
pot ser utilitzat sense sobrecarregar la aplicació amb parts
innecesàries gràcies al disseny modular de Spring. De fet el propi framework
utilitza la seva implementació d'AOP per implementar \emph{cross-cutting
concerns} com seguretat, transaccions\ldots\\

Comparat amb AspectJ és menys potent, més senzill d'utilitzar i possiblement
requereix menys recursos.\\

Spring AOP està basat en intercepcions. Això és a l'hora el taló d'Aquiles (ja
que limita l'actuació dels aspectes a mètodes \em{public} ó
\em{protected}) en objectes existens i a l'hora un punt interessant ja que
amb aquesta limitació ens estalviem el pas previ de compilació, és a dir,
funciona com una llibreria normal, a diferència d'AspectJ, que requereix del
procés de \em{weaving}).

\end{itemize}

